Specifying Processes in the Procgroup File

procgroup files

The procgroup file is the only portion of the interface that is very likely to change through multiple versions of p4. As new architectures are supported, it is hoped that we can merely alter the procgroup file format to reflect any new features. (Of course new procedure calls may also be required, but existing procedure calls will remain unchanged when possible).

The current format of a procgroup file is as follows:
\begin{example}
local n [full_path_name] [loginname]
remote_machine n full_path_name [loginname]
.
.
.
\end{example}

On cube and mesh architectures, the program is started via some special command executed from the host machine. In such cases, the procgroup file name can be specified to the special command line along with the program name (see for example the runcube and rundelta shell scripts in the p4/messages subdirectory). In those cases where no special command is required, no special handling is required for the procgroup filename.

The first line of a procgroup file must be ``local n'' where n is the number of slave processes that are in the same cluster as the master. The full path name on the ``local'' line is ignored on machines other than cube and mesh machines. The subsequent lines contain either three or four fields:

  1. the name of a remote machine on which slave processes are to be created.
  2. the number of slaves that are to be created on that machine, i.e. be in the same cluster (note that on machines that support it, the processes in a cluster will share memory)
  3. the full path name of the executable slave program
  4. optionally, the user login name on the remote machine, if different from that on the host machine.

As an example, let's assume that you have a network of three Sun workstations named sun1, sun2, and sun3. We will also assume that you are working on sun1 and plan to run a master process there. If you would like to run one process on each of the other Suns, then you might code a procgroup file that looks like:


\begin{example}
...

Lines beginning with # are comments.

Next, let's assume that you have a Sequent Symmetry (named symm) and an Encore Multimax (named mmax). We will also assume that you are working on symm, and plan to run the master there. If you would like to run two processes on symm (in addition to the master) and two on mmax, then you might code a procgroup file that looks like:


\begin{example}
local 2
mmax 2 /mmaxfs/mylogin/p4pgms/sr_test
\end{example}

P4 also permits you to treat the symmetry as a remote machine even when you are running the master there. Thus, you might code a procgroup file as follows:


\begin{example}
local 2
symm 2 /symmfs/mylogin/p4pgms/sr_test
mmax 2 /mmaxfs/mylogin/p4pgms/sr_test
\end{example}

In this example, there are seven processes running. Five of the processes are on symm, including the master. Two of the processes on symm are in the master's procgroup and two are running in a separate procgroup as if they were on a separate machine. Of course, the last two are running on mmax.

Some notes about the contents of the procgroup file should be made at this point. First, the value of n on the local line can be zero, i.e. the master may have no local slaves. Second, the local machine may be treated as if it is a remote machine by merely entering it in some line as a remote machine. Third, a single machine may be treated as multiple remote machines by having the same remote machine name entered on multiple lines in the procgroup file. Fourth, if a single machine is listed multiple times, those processes specified on each line form a single cluster (share memory). Fifth, the cluster size specified for a uniprocessor should be 1, because all slaves in a cluster are assumed to run in parallel and to share memory.

We refer to the original (master) process as the ``big master''. The first process created in each cluster is the ``remote master'' or the ``cluster master'' for that cluster. All p4-managed processes (see the procedure p4_create_procgroup) have unique integer id's beginning with 0. The processes within a cluster are numbered consecutively.

Developing a Simple p4 Program,Command-Line Arguments,Specifying Processes in the Procgroup File,Top